Сегодня мы обобщим новости о VMware vSphere 5 и приведем несколько новых интересных фактов. Итак:
1. Новые версии VMware vSphere 5, VMware vCenter 5, а также новый продукт vSphere Storage Appliance (VSA) станут доступными к заказу 22 августа 2011 года. Естественно, по новым ценам. Как можно узнать из нашей статьи, цены на лицензии и поддержку для продуктов поднимаются для России на 20% и будут, в итоге, на 30% выше цен для Северной Америки.
2. Все пользователи VMware vSphere 4.x с действующей поддержкой и подпиской получают VMware vSphere 5 бесплатно. Схема перехода комплектов лицензий на 5.0 такова:
3. Как вы могли заметить из таблицы выше, издание VMware vSphere Advanced упраздняется. Все пользователи VMware vSphere 4.x Advanced с действующей поддержкой и подпиской получают VMware vSphere 5 Enterprise бесплатно. Соответственно, оптимальное решение сейчас - купить VMware vSphere Advanced (или Advanced Acceleration Kit) до 22 августа и после этой даты получить VMware vSphere Enterprise совершенно бесплатно. Подробности тут.
4. Снимаются ограничения на число ядер для всех изданий VMware vSphere 5, но вводятся ограничения по максимальной сконфигурированной памяти запущенных на хосте виртуальных машин в соответствии с количеством памяти, определенной лицензией на базе процессоров. Более подробнее читайте тут.
Самая свежая на данный момент информация о максимальных значениях для vRAM в рамках лицензии для каждого из изданий (кликабельно):
Обратите внимание: информация изменилась, лимиты по памяти увеличились.
Как вы помните, используемую память можно расширить либо закупкой новых лицензий для этого издания, либо апгрейдом текущих лицензий на более высокое издание, позволяющее использовать больше памяти ВМ на физический процессор хост-сервера. Для изданий Essentials и Essentials Plus лимит по памяти расширить никак нельзя (нужно делать апгрейд на новый пакет лицензий Acceleration Kit).
Важный момент - при превышении лимита по памяти для изданий Essentials и Essentials Plus будет невозможно запустить новые виртуальные машины (hard limit), для остальных изданий - просто будет выведен Alert о том, что превышен лимит vRAM (но все продолжит работать в штатном режиме).
Если у вас несколько лицензий для каждого из изданий - пул vRAM считается для каждого издания отдельно.
5. Появляется новая лицензия VMware vSphere 5 Desktop. Эта лицензия для тех, кто не будет использовать VMware View для работы с виртуальными ПК предприятия, а хочет использовать сторонний брокер соединений (например, Citrix XenDesktop). Минимальный объем закупки - 100 виртуальных ПК. При этом неважно сколько хост-серверов VMware ESXi 5 вы будете использовать для этих ПК.
6. Для пользователей, не вдохновившихся новой политикой VMware касательно лицензирования по сконфигурированной памяти, есть возможность даунгрейда на VMware vSphere 4.x с пятой версии. Это возможно и для части лицензий (апгрейд тоже можно сделать не для всех своих лицензий 4.x).
7. Изменился состав пакета VMware vSphere 5 Enterprise Plus Acceleration Kit - он включает в себя лицензии для 6 процессоров (ранее они были на 8 процессоров).
8. Интересная фишка - если ваша ВМ потребляет памяти более 96 ГБ (например, 128 ГБ), то в пуле учета памяти для лицензирования она считается все равно как 96 ГБ.
9. С 22 августа станут недоступны к заказу все поддержки на 2 года. Вот такая штука, да.
10. Будет две интересных промо-программы: промоапгрейд с vSphere 5 Enterprise на vSphere 5 Enterprise Plus (со скидкой) и промопакет vSphere 5 Essentials Plus с продуктом VSA. Об этом напишем отдельно.
Во время установки ESXi 5 установщик имеет несколько опций по сохранению предыдущих настроек VMware ESX и хранилищ VMFS.
Кстати, вот еще несколько мыслей об обновлении хостов с vSphere 4 на vSphere 5. И самая главная мысль - как выйдет ESXi 5 не надо рваться в первых рядах и обновлять хост-серверы, тома VMFS, Virtual Hardware и прочее в своей производственной среде. Подождите хотя бы 2-3 недели пока что напишут о багах и недоделках.
Вот как только вышла vSphere 4 мы поехали к заказчику (немаленькому) ставить ее на демо-стенде. Он выбирал между vSphere и Hyper-V. Мы сделали HA-кластер, начинаем показывать - бах, кластер не заводится после выключения хоста, машинки не стартуют. А оказалось - бага, которую почти сразу после нашего отъезда пофиксили. А заказчик он посмотрел, побурчал и поставил там Hyper-V. Так вот.
Вы уже читали, что в VMware vSphere 5 механизм отказоустойчивости виртуальных машин VMware High Availability претерпел значительные изменения. Точнее, он не просто изменился - его полностью переписали с нуля. То есть переделали совсем, изменив логику работы, принцип действия и убрав многие из существующих ограничений. Давайте взглянем поподробнее, как теперь работает новый VMware HA с агентами Fault Domain Manager...
Таги: VMware, vSphere, HA, Update, ESXi, Storage, vCenter, FDM
Теперь пришел черед VMware vCloud Director 1.5, продукта который позволяет построить платформу облачных вычислений для частных облаков на базе VMware vSphere 5 (см. наши упоминания тут и тут).
Напомним вкратце что это такое и для чего нужен vCloud Director. VMware vCloud Director - это надстройка над инфраструктурой vSphere, которая позволяет создавать безопасные (vShield 5) гибридные облака с поддержкой нескольких арендаторов путем объединения ресурсов инфраструктуры в виртуальные ЦОД. Ресурсы этого датацентра предоставляются по требованию (см. vCloud Connector) в рамках определенного рабочего процесса.
vCloud Director объединяет ресурсы ЦОД (вычислительные ресурсы, хранилище и сеть) и соответствующие политики в виртуальные ЦОД. Полностью инкапсулированные многоуровневые виртуальные сервисы пользователей предоставляются в виде объектов vApp в формате OVF (наборы ВМ для одной задачи). Конечные пользователи и соответствующие политики объединяются в организации. Компоненты инфраструктуры, пользователи и услуги объединяются в логические пулы (управляются на основе политик), которые соответствуют определенным уровням обслуживания.
В vCloud Director есть каталог уже готовых стандартизированных приложений в ВМ, которые готовы к развертыванию со стороны пользователей (через портал самообслуживания). Эти vApp предоставляются как услуга на базе платы за использование (Pay as you go).
Чтобы лучше понять для чего нужен и как устроен VMware vCloud Director нужно посмотреть вот эту презентацию:
А теперь о новых возможностях VMware vCloud Director 1.5. Общая картина:
Появилась поддержка связанных клонов (Linked Clones) для выделяемых ВМ:
Появилась возможность кастомизации гостевых ОС и свойств шаблона OVF для автоматизации развертывания новых сервисов и их автоматической постконфигурации:
Появилась интеграция с различными Enterprise-системами за счет механизма vCloud Messaging в vCloud API:
Ну и вкратце остальные возможности:
Интеграция с распределенным коммутатором Cisco Nexus 1000V
Поддержка Microsoft SQL Server в качестве БД
Интеграция с vShield Edge VPN
Ну и, конечно, поддержка VMware vSphere 5
VMware vCloud Director 1.5 будет доступен в 3-м квартале 2011 года, вместе с VMware vSphere 5, по цене от $150 за виртуальную машину.
Хотим напомнить еще раз, что продукт компании "Код Безопасности" vGate R2 - это лучшее средство для обеспечения безопасности вашей виртуальной инфраструктуры (в том числе, на базе VMware ESXi с сертфикатом ФСТЭК), а также для автоматизированной ее настройки в соответствии с требованиями ИБ.
Теперь пара новостей. Первая:
vGate-S R2 – первое в России сертифицированное средство защиты государственной тайны в виртуальной среде
Компания «Код Безопасности» объявляет об успешном прохождении продуктом vGate-S R2 сертификационных испытаний и получении им сертификата ФСТЭК России, согласно которому продукт может применяться для защиты государственной тайны в автоматизированных системах до класса 1Б включительно. Таким образом, продукт vGate-S R2 стал первым и единственным в России сертифицированным средством защиты государственной тайны от несанкционированного доступа в виртуальной среде.
Что это значит? Это значит, что если ваша организация работает с гостайной, и вы используете VMware vSphere - то у вас просто нет альтернатив, кроме как купить vGate-S R2.
Вторая новость:
Продукт vGate R2 стал победителем первого этапа Конкурса продуктов VirtualizationSecurityGroup.Ru в номинации Access Control
Продукт vGate R2 разработки компании «Код Безопасности» стал победителем первого этапа Конкурса продуктов (в номинации Access control), организованного некоммерческим объединением специалистов Virtualization Security Group Russia и порталом VirtualizationSecurityGroup.Ru.
Следующим этапом конкурса станет открытое голосование на портале VirtualizationSecurityGroup.Ru за видео-ролики, которые подготовили компаний-участники по своим продуктам. Голосование за видео-ролики по продуктам на портале VirtualizationSecurityGroup.Ru продлится десять дней. Победители Конкурса продуктов будут объявлены 4 августа на сайте организатора. По результатам двух этапов организаторы объявят победителей в трех номинациях Конкурса (Access Control, Network Protection, Antivirus/Anti-Malware), а самая оригинальная и интересная видео-презентация будет отмечена в номинации «Best of Show».
В Конкурсе также приняли участие продукты для защиты виртуальных инфраструктур компаний Cisco, HP, Trend Micro, McAfee, IBM, Symantec. Вне Конкурса были представлены продукты компаний ОКБ Сапр, Stonesoft.
Вместе с релизом продуктовой линейки VMware vSphere 5, VMware SRM 5 и VMware vShield 5 компания VMware объявила о выходе еще одного продукта - VMware vSphere Storage Appliance. Основное назначение данного продукта - дать пользователям vSphere возможность создать общее хранилище для виртуальных машин, для которого будут доступны распределенные сервисы виртуализации: VMware HA, vMotion, DRS и другие.
Для некоторых малых и средних компаний виртуализация серверов подразумевает необходимость использовать общие хранилища, которые стоят дорого. VMware vSphere Storage Appliance предоставляет возможности общего хранилища, с помощью которых малые и средние компании могут воспользоваться средствами обеспечения высокой доступности и автоматизации vSphere. VSA помогает решить эти задачи без дополнительного сетевого оборудования для хранения данных.
Кстати, одна из основных идей продукта - это подвигнуть пользователей на переход с vSphere Essentials на vSphere Essentials Plus за счет создания дополнительных выгод с помощью VSA для распределенных служб HA и vMotion.
Давайте рассмотрим возможности и архитектуру VMware vSphere Storage Appliance:
Как мы видим, со стороны хостов VMware ESXi 5, VSA - это виртуальный модуль (Virtual Appliance) на базе SUSE Linux, который представляет собой служебную виртуальную машину, предоставляющую ресурсы хранения для других ВМ.
Чтобы создать кластер из этих виртуальных модулей нужно 2 или 3 хоста ESXi 5. Со стороны сервера VMware vCenter есть надстройка VSA Manager (отдельная вкладка в vSphere Client), с помощью которой и происходит управление хранилищами VSA.
Каждый виртуальный модуль VSA использует пространство на локальных дисках серверов ESXi, использует технологию репликации в целях отказоустойчивости (потому это и кластер хранилищ) и позволяет эти хранилища предоставлять виртуальным машинам в виде ресурсов NFS.
Как уже было сказано, VMware VSA можно развернуть в двух конфигурациях:
2 хоста ESXi - два виртуальных модуля на каждом хосте и служба VSA Cluster Service на сервере vCenter.
3 хоста ESXi - на каждом по виртуальному модулю (3-узловому кластеру служба на vCenter не нужна)
С точки зрения развертывания VMware VSA - очень прост, с защитой "от дурака" и не требует каких-либо специальных знаний в области SAN (но во время установки модуля на хосте ESXi не должно быть запущенных ВМ)...
Как вы знаете, мы очень любим компанию Код Безопасности и продукт vGate R2 для обеспечения защиты виртуальных инфраструктур VMware vSphere, который они выпускают (подробнее тут). Любим мы его не только за то, что он хорошо работает и на отлично справляется как с задачей автоматизированной настройки виртуальной среды в соответствии с требованиями ИБ, так и с задачей защиты от несанкционированного доступа. Мы любим его еще и за то, что у него есть сертификаты ФСТЭК, которые так важны при общении с органами на предмет соответствия ФЗ 152.
Собственно, об этом и первая новость. Как мы уже писали, поскольку VMware vSphere 5 построена только на базе VMware ESXi, Код Безопасности выпустил версию vGate R2 с поддержкой ESXi 4.1 и подал ее на прохождение инспекционного контроля ФСТЭК.
Теперь vGate R2 этот инспекционный контроль успешно прошел:
Новая версия vGate R2 с поддержкой ESXi прошла инспекционный контроль во ФСТЭК России.
Компания «Код Безопасности» сообщает об успешном прохождении новой версии vGate R2 c поддержкой VMware ESXi Server 4.1 инспекционного контроля и подтверждении выданного ранее сертификата ФСТЭК России (№2308) на соответствие требованиям по 4-му уровню контроля отсутствия НДВ и 5-му классу защищенности от несанкционированного доступа.
Ключевыми особенностями новой версии продукта vGate R2 являются: поддержка VMware ESXi Server 4.1 и новые шаблоны безопасности по требованиям ФСТЭК для автоматизированных систем государственного сектора России, по требованиям ФСТЭК к информационным системам персональных данных и по требованиям отраслевого стандарта СТО БР ИББС (РС БР ИББС 2.3-2010). vGate R2 позволяет значительно облегчить приведение виртуальной инфраструктуры VMware, в которой обрабатывается информация ограниченного доступа, не содержащая государственную тайну, в соответствие требованиям отечественных и международных отраслевых стандартов и регулирующих органов России.
Продажа продукта vGate R2 c поддержкой ESXi откроется 1 августа 2011 года.
Скачать сертификат ФСТЭК для vGate R2 можно по ссылке:
Обратите внимание, что покупать сертифицированный продукт vGate R2 можно уже с 1-го августа.
Ну и вторая новость - по данным сайта anti-malware.ru (а это еще и информационно-аналитический центр Anti-Malware) продукт vGate R2 - хорош в плане обеспечения ИБ VMware vSphere. Об этом можно почитать в результатах тестирования продукта у этих ребят на тестовом стенде.
Эксперты Anti-Malware отметили «необходимость использования продукта vGate R2, который позволяет дополнить систему защиты от несанкционированного доступа и контроля выполнения политик информационной безопасности с учетом специфики виртуальной среды». По оценочной шкале Anti-Malware продукт vGate R2 получил 9 из 10 баллов.
Мы уже не раз писали об обновленной линейке продуктов VMware vShield (тут, тут и тут). Вместе с релизом VMware vSphere 5 компания VMware также объявила о выпуске VMware Site Recovery Manager 5 и VMware vShield 5. Сегодня мы поговорим о последнем из перечисленных продуктов.
Итак, давайте взглянем на общую картину решения VMware vShield 5:
Как мы помним, в VMware vShield есть 3 ключевых компонента:
vShield Edge - защищающий периметр датацентра.
vShield App with Data Security - защищающий виртуальные машины на хост-серверах VMware ESXi (контроль трафика по портам и протоколам). Обратите внимание, что появился новый компонент Data Security (его, кстати, будут давать бесплатно ко многим продуктам).
Всеми этими компонентами в той или иной степени управляет VMware vShield Manager, который представляет собой надстройку к VMware vCenter.
Теперь взглянем на список новых возможностей VMware vShield 5 (которые соответствуют потребностям заказчика из левой колонки):
По сути, в vShield 5 появилось 3 новых ключевых возможности. Рассмотрим их детальнее.
1. Система обнаружения конфиденциальных данных для соблюдения стандартов и нормативов.
Эта функциональность реализована в компоненте vShield Data Security 5, который поставляется вместе с vShield App 5 (который, в свою очередь, является виртуальным модулем - Virtual Appliance и работает на каждом хосте ESXi). Это продукт позволяет обнаруживать конфиденциальные данные (таких как информация о банковских картах, личные данные) которые могут быть сохранены внутри документов в виртуальных машинах (это делается за счет технологии Data Loss Prevention от RSA, DLP, которая может выявлять данные из файлов, например, PDF). На базе этого анализа делается заключение о данных, нуждающихся в защите с помощью политик безопасности. Самое интересное, что это делается без агентов.
Далее организации могут выбирать из более 80 шаблонов нормативных требований, таких как PII (личные данные), данные держателей карт PCI-DSS и PHI (защищенные медицинские данные), из различных стран (Северная Америка, Европа, Ближний Восток и Африка, Азиатско-Тихоокеанский регион). России тут нет - для нас есть продукт vGate R2 от компании Security Code.
Эти шаблоны содержат в себе наборы определенных политик безопасности, которые можно применить к хост-серверам ESXi 5 и виртуальным машинам (для каждой отрасли свои требования). Элементы виртуальной инфраструктуры VMware vSphere 5 (datacenter, file share, resource pool, host, VM) можно просканировать на предмет соответствия этим политикам. После этого будет получен детальный отчет о том, какие объекты и в чем именно не соответствуют требованиям стандартов.
Этот механизм имеет собственный API. Далее проблемные виртуальные машины можно исправлять вручную (но это долго и муторно) либо с помощью VMware vCenter Configuration Manager (перед этим эти машины можно поместить в карантин). Российским пользователям лучше использовать продукт vGate R2, сертифицированный ФСТЭК.
2. Возможность карантина виртуальных машин.
В VMware vShield есть возможность интеграции со сторонними виртуальными модулями, в которых реализован механизм обнаружения и предотвращения вторжений (IDS/IPS-системы). Такая система, выявившая подозрительную виртуальную машину, может поместить ее на карантин за счет механизма VMware vShield App 5.
Машины, находящиеся в карантине, полностью изолированы от производственной среды, их можно исследовать и исправлять. После исправления (удаление вирусов, ликвидация угроз, приведение в соответствие политикам ИБ) ее можно вернуть снова в production.
Эта функциональность может быть использована компонентом vShield Data Security, а также сторонними поставщиками ативирусных продуктов через API.
3. Повышение эффективности антивирусных решений.
Помимо функциональности помещения виртуальных машин в карантин, теперь в полную силу заработала технология сканирования виртуальных машин на уровне гипервизора, без агентов, на предмет наличия вредоносного ПО (ранее мы об этом писали). Антивирусное решение, поставляемое в виде виртуального модуля (Virtual Appliance), находится на каждом хосте ESXi 5 и обеспечивает проверку виртуальных машин на вирусы (см. компонент vShield Endpoint), после чего ПО в этом модуле может "лечить" зараженные ВМ после помещения в карантин.
VMware vSphere 5 знает о наличии таких специальных сервисных виртуальных машин, обеспечивающих безопасность, поэтому не перемещает их между хостами за счет технологии DRS.
VMware vShield 5 можно купить по отдельным компонентам (например, vShield App), кроме того, некоторые компоненты vShield 5 идут в комплекте поставки некоторых продуктов VMware (например, VMware View - там идет Endpoint). Также все компоненты vShield 5 можно купить в составе vShield Bundle.
За более подробной информацией обращайтесь в компанию VMC, которая, в том числе, оказывает услуги по внедрению инфраструктуры безопасности для VMware vSphere 5.
Компания StarWind Software, выпускающая самый лучший продукт для создания iSCSI-хранилищ для ваших серверов VMware vSphere и Mirosoft Hyper-V (см. тут и тут), объявила о выпуске решения StarWind Enterprise 5.7, которое предоставляет еще больше возможностей по созданию отказоустойчивых хранилищ (само собой, есть бесплатная версия StarWind 5.7 Free).
Этот релиз StarWind Enterprise 5.7 представляет собой первый шаг по переводу механизма отказоустойчивости хранилищ на новую архитектуру.
Перечислим основные новые возможности StarWind 5.7:
1. Улучшения механизма синхронизации. Теперь отсылка данных между узлами отказоустойчивого кластера происходит в асинхронном режиме. Это означает, что StarWind Enterprise HA теперь работает заметно быстрее. Подробности нового механизма работы HA вы можете прочитать в блоге у Константина, а мы приведем основную суть.
Ранее все работало следующим образом:
Когда iSCSI-пакет приходит на основной узел, он отправляет его на резервный. После того, как резервный узел получает пакет, он посылает iSCSI-команду подтверждения получения блока данных (ACK), только после получения которой основной узел передает ACK инициатору и записывает пакет на диск. Когда iSCSI-команд становилось много, они ставились в очередь и происходили некоторые задержки, поскольку постоянно нужно было совершать эти итерации.
Теперь все работает так (некий гибрид синхронного и асинхронного процессов):
Когда iSCSI-пакет приходит на основной узел, он отправляет его на резервный. И, не дожидаясь ACK от партнера, сразу посылается второй пакет. Когда очередь закончится, и второй узел запишет данные на диск, он отсылает ACK основному узлу, которые его уже передает инициатору. Так все работает значительно быстрее. Ну и защита от потери данных при сбое в канале синхронизации тоже есть.
2. Улучшения High availability. Появилось управление полосой пропускания канала синхронизации (QoS) - теперь можно регулировать приоритезацию трафика при синхронизации HA-узлов, что позволяет не забивать весь доступный канал и не затормаживать доступ к общему хранилищу. Для этого нужно выбрать пункт "Sync channel priorities" из контекстного меню HA-устройства.
По умолчанию для наибольшей безопасности приоритет стоит у канала синхронизации. Выставлять QoS нужно только на основном узле, на резервном он выставится автоматически.
3. Оптимизация канала. Теперь для оптимизации канала используется несколько параллельных iSCSI-сессий. В следующей версии StarWind Enterprise 5.8 это количество можно будет регулировать, а также возможна будет настройка количества каналов для Heartbeat.
4. Performance Monitoring - возможность отслеживания производительности дисковой подсистемы из Management Console (disk transfer rate, average number of I/O operations on targets, CPU and memory load on StarWind server). Выглядит это так:
5. Новая полезная оснастка - Snapshot Manager. Теперь можно управлять снапшотами через GUI. Для этого в контекстном меню для устройства нужно выбрать пункт "Snapshot Manager".
6. Улучшенный Event log. Теперь при наступлении события происходит нотификация администратора через иконку в System Tray.
7. Улучшения GUI. Теперь Targets и серверы могут объединяться в группы для удобства управления.
8. Экспериментальный "deduplication plugin". Он позволяет установить дедупликацию с размерами блока от 512Б до 256КБ на выбор (вместо 512Б сейчас), что позволяет увеличить производительность процесса дедупликации до десяти раз, при этом экономия пространства на дедупликации уменьшается всего на 10-15% (при сравнении 512 байтовых с 4кб блоками). Кроме того, значительно понизится нагрузка на ЦПУ и 90% уменьшятся требования к объёму ОЗУ.
9. ImageFile, DiskBridge. Поддержка режима Mode Sense page 0x3 для совместимости с iSCSI-инициатором Solaris.
Как вы знаете, только у нас вы можете прочитать самый полный список новых возможностей VMware vSphere 5 на русском языке, новой версии платформы виртуализации, которая выйдет в третьем квартале этого года (скорее всего, сразу после VMworld 2011). Новая версия будет построена только на базе VMware ESXi 5.
Сегодня мы хотим рассказать о новой версии VMware ESXi 5, которая (не волнуйтесь) останется в бесплатном варианте (правильно бесплатную версию VMware ESXi 5 нужно называть VMware vSphere Hypervisor). Но поскольку правила лицензирования теперь изменились (об этом там же), то нужно знать о важном ограничении, которое повлияет на большинство пользователей малого и среднего бизнеса, а именно:
Бесплатный VMware ESXi 5 позволяет использовать сколько угодно виртуальных машин на сервере, который имеет сколько угодно процессоров и ядер, но совокупная сконфигурированная память всех включенных виртуальных машин не должна превышать 32 ГБ.
Что такое сконфигурированная память виртуальной машины? Это та, которую вы выставляете в настройках при ее создании.
Звучит плохо, не правда ли - 32 ГБ памяти для всех запущенных виртуальных машин на сервере с бесплатным VMware ESXi 5? Но это так. Понятно дело, что для VMware ESXi 4.1 у вас на сервере для виртуальных машин, зачастую, выставлено больше памяти. Но этот тот способ, за счет которого VMware заставит вас купить хотя бы VMware vSphere 5 Essentials, где уже для каждого физического процессора сервера позволяется использовать 24 ГБ сконфигурированной памяти виртуальных машин (а значит, 48 ГБ на двухпроцессорный сервер).
VMware vSphere Hypervisor is a free product that provides a simple
and easy way to get started with virtualization at no cost...vSphere Hypervisor is entitled to 32GB of vRAM per server (regardless of the number of processors) and can be
utilized on servers with up to 32GB of physical RAM.
Хочется знать, то такое vRAM? Не проблема - vRAM is the entitlement of pooled virtual memory used across all active virtual machines on the system. Кстати, обратите внимание, что бесплатный VMware ESXi 5 можно использовать только на серверах, где установлено до 32 ГБ физической RAM.
Ну и, конечно, вам хочется знать, что произойдет, если вы превысите планку Entitled vRAM. В этом случае, после лимита в 32 ГБ, новая виртуальная машина просто не включится (это предварительная информация). Все очень просто - hard limit.
А вот какие улучшения и новые возможности появятся в бесплатном VMware ESXi 5:
8 виртуальных процессоров для виртуальной машины (vCPU)
Улучшенный фаервол для VMware ESXi 5 (см. видео тут)
Поддержка устройств USB 3.0
GUI для редактирования количества виртуальных ядер на виртуальный процессор
USB-устройства, подключаемые к ВМ со стороны клиента
Поддержка больших томов VMFS и RDM (до 64 ТБ) в VMFS 5
Поддержка EFI BIOS и гостевых ОС Mac OS 10.6
Поддержка смарт-карт для доступа к консоли виртуальных машин
Поддержка 3D-графики и Windows Aero
Становится понятным, что теперь возможны два варианта: или под давлением общественности VMware повысит планку используемой памяти для бесплатного VMware ESXi 5, или пользователи начнут массовые миграции на Microsoft Hyper-V и Citrix XenServer, которые потихоньку набирают силу в сегменте малого и среднего бизнеса.
Оставайтесь с нами. Еще интереснее дальше будут вещи. Кстати, по vSphere 5 появился еще вот такой интересный документик.
Как вы знаете, на днях было объявлено о выходе платформы виртуализации VMware vSphere 5. Наше любимое средство обеспечения информационной безопасности vGate R2 от компании Security Code, безусловно, будет поддерживает ее либо еще до выхода продукта, либо сразу после него (а пока о vGate R2 почитайте тут и тут, а также про поддержку ESXi).
VMware также объявила о выходе решения VMware vShield 5 для обеспечения безопасности vSphere 5, но если вы посмотрите сюда, то увидите, что vGate является наиболее эффективным средством защиты, в отличие от нишевого продукта vShield.
А сегодня мы поговорим о том, как дополнительно можно защитить инфраструктуру VMware vSphere, в которой работает средство vGate R2, ведь помимо программных средств обеспечения безопасности, нужно обезопасить инфраструктуру еще и на физическом уровне в организациях с повышенными требованиями к ИБ и в компаниях, работающих с конфиденциальными данными. Кроме того, актуальна проблема защиты данных внутри виртуальных машин, которые для VMware являются, по-сути, "черными ящиками".
Продукт Secret Net является сертифицированным средством защиты информации от несанкционированного доступа и позволяет привести автоматизированные системы в соответствие требованиям регулирующих документов:
№98-ФЗ ("О коммерческой тайне")
№152-ФЗ ("О персональных данных")
№5485-1-ФЗ ("О государственной тайне")
СТО БР (Стандарт Банка России)
Этот продукт можно использовать для защиты от несанкционированного доступа следующих объектов виртуальной инфраструктуры vSphere:
Защита виртуальных машин от НСД (разграничение доступа, контроль устройств, управление политиками доступа к информации в гостевой ОС, мониторинг и аудит событий ИБ).
Защита сервера авторизации vGate R2 (несанкционированный доступ к функциям администратора информационной безопасности). Надо отметить, что сервер авторизации также может быть физической машиной, что требует дополнительных мер по его защите (см. ПАК "Соболь").
Защита рабочего места администратора VMware vSphere (не является компонентов виртуальной инфраструктуры, а значит требует дополнительной защиты)
Более детально о продукте Secret Net можно почитать здесь.
Электронный замок «Соболь» - это аппаратно-программное средство защиты компьютера от несанкционированного доступа (аппаратно-программный модуль доверенной загрузки).
Если виртуальные машины мы можем защитить за счет их доверенной загрузки средствами vGate R2, то физические компоненты виртуальной инфраструктуры нужно наиболее тщательно защищать от злоумышленников за счет специализированных аппаратно-программных средств. Таким средством и является ПАК "Соболь" (как видно из картинки, это специальная плата и ПО). Его можно использовать для защиты следующих объектов виртуальной инфраструктуры vSphere:
Доверенная загрузка сервера авторизации vGate R2
Доверенная загрузка серверов ESXi и ESX
В качестве альтернативного или дополнительного метода защиты сервера авторизации и серверов ESX / ESXi могут применяться организационные меры, заключающиеся в физическом
ограничении доступа к оборудованию со стороны возможных нарушителей.
Более подробно о ПАК "Соболь" можно почитать здесь.
Все эти средства прекрасно живут и работают с vGate R2. Если есть какие-то вопросы - задавайте в каментах.
Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.
Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.
Сегодня мы поговорим о защите от несанкционированного доступа к различным компонентам инфраструктуры VMware vSphere с помощью vGate R2. Мы уже писали о том, как с помощью vGate R2 можно автоматически настроить vSphere в соответствии с политиками ИБ, а также обсуждали экономический эффект, а теперь углубимся в защиту от НСД...
На сегодняшний день есть несколько средств для анализа текущего состояния виртуальной инфраструктуры VMware vSphere на предмет соответствия требованиям информационной безопасности, а также непосредственно для обеспечения этой самой безопасности.
Наиболее популярны продукты Security Code vGate R2 и VMware vShield (у обеих компаний есть бесплатные анализаторы безопасности vSphere - vGate Compliance Checker и VMware Compliance Checker). Но, дело в том, что нужны они для совершенно разных целей. Причем vGate R2 на практике для пользователей VMware оказывается значительно полезнее vShield, поскольку последний сосредоточен только на сетевой защите (+ интеграция с антивирусами), а vGate R2 позволяет автоматически настроить среду VMware vSphere в соответствии с требованиями ИБ на базе политик, а также защитить различные объекты инфраструктуры от несанкционированного доступа. К тому же, vGate еще имеет сертификат ФСТЭК, что немаловажно для российских компаний, стремящихся обеспечить соответствие нормам ФЗ 152.
Давайте посмотрим на сравнение функциональности продуктов vGate R2 и vShield в разрезе задач по обеспечению ИБ, которые стоят перед компаниями, использующими виртуализацию VMware. Информация взята из брошюры "Cравнение функциональных возможностей vGate R2 и VMware vShield". В таблице также приведены возможности продукта TrustAccess, который также делает компания Код Безопасности.
Возможности/показатели
vGate R2
TrustAccess
vShield (App+Edge+Endpoint/Zones)
Межсетевое экранирование различных типов
Дополнительные лог-файлы событий
информационной безопасности
Контроль доступа к элементам инфраструк-
туры (дискреционное и мандатное управление доступом)
Автоматическое приведение конфигурации
виртуальной инфраструктуры в соответствие положениям PCI DSS, VMware Security
Hardening Best Practice и CIS VMware ESX
Server 3.5 Benchmark
Согласование готовой виртуальной машины
у администратора информационной безопасности
Запрет доступа администраторов виртуальных инфраструктур к данным виртуальных
машин
Создание отчетов о произошедших событиях
информационной безопасности и внесенных
изменениях в конфигурацию
Создание отчетов о соответствии PCI DSS,
VMware Security Hardening Best Practice и
CIS VMware ESX Server 3.5 Benchmark
Создание отчетов о текущем статусе конфигурации системы безопасности
Регистрация попыток доступа к инфраструктуре
Контроль целостности и доверенная
загрузка виртуальных машин
Сертификаты ФСТЭК России для защиты
конфиденциальной информации и персо-
нальных данных
СВТ5, НДВ4
(АС 1Г и ИСПДн К1)
МЭ2, НДВ4
(АС 1Г и ИСПДн К1)
Сертификаты ФСТЭК России для защиты
государственной тайны
СВТ3, НДВ2
(АС 1Б и ИСПДн К1)
*Проходит сертификационные испытания
МЭ2, НДВ2
(АС 1Б и ИСПДн К1)
Как видно из таблицы, vGate R2 обеспечивает очень много возможностей тем организациям, которые хотят правильно настроить конфигурацию VMware vSphere с точки зрения безопасности, а также защитить ее от НСД, особенно от своих собственных администраторов (для этого все действия фиксируются и попадают в отчет).
Если говорить о стоимости решения Кода Безопасности, то она вполне кокурентна:
Вариант покупки / Продукт
vGate R2
TrustAccess
vShield App
vShield Edge
vShield Zones
vShield Manager
vShield Endpoint
Ориентировочная стоимость решения Кейс 1
небольшая инфраструктура
30 виртуальных машин
(15 с серверными операционными системами)
3 сервера
(по 2 физических процессора)
236,000 руб.
195,000 руб.
263,465 руб.
263,465 руб.
87,840 руб.
Бесплатный (вклю-
чен в поставку
некоторых редакций
vSphere)
Бесплатный
(при условии
покупки одного из
продуктов семей-
ства vShield)
Ориентировочная стоимость решения Кейс 2
инфраструктура средних размеров
100 виртуальных машин
(50 с серверными операционными системами)
10 серверов
(по 2 физических процессора)
579,000 руб.
575,000 руб.
526,931 руб.
526,931 руб.
175,681 руб.
--
--
Ориентировочная стоимость решения Кейс 3
крупная инфраструктура
200 виртуальных машин
(100 с серверными операционными системами)
20 серверов
(по 2 физических процессора)
1069,000 руб.
1110,000 руб.
1053,862 руб.
1053,862 руб.
351,362 руб.
--
--
Бесспорно, и у vShield есть несколько преимуществ перед vGate R2, ведь vGate не замахивается на нишу vShield (я бы сказал, что продукты дополняют друг друга). Но если дело касается практических задач ИБ на предприятии, то vGate R2 - куда полезнее.
Мы уже писали о некоторых расширенных настройках дисковой подсистемы серверов VMware ESX / ESXi, которые позволяют управлять доступом виртуальных машин к хранилищам VMFS. Сегодня постараемся описать еще несколько параметров:
Опишем еще несколько параметров Advanced Settings для категории Disk:
Disk.MaxLUN - это число (по умолчанию 256, т.е. ID от 0 до 255), опеделяющее максимальное количество томов, доступных серверу VMware ESX / ESXi.
Disk.MaskLUNs = "vmhba1:0:32-35;vmhba2:0:1,5,7-9" - это параметр, определяющий маскирование томов VMFS в SAN. В данном примере от хоста ESX / ESXi скрываются LUN с ID от 32 до 35 для HBA-адаптера vmhba1, а также LUN с ID 1,5,7,8,9 для адаптера vmhba2. Разделитель для адаптеров - точка с запятой.
Disk.SupportSparseLUN - эта настройка включена по умолчанию (значение 1), по желанию ее можно выставить в 0. Значение 1 означает, что на ESX / ESXi включена поддержка номеров LUN, идущих непоследовательно (например, 0,6 и 23). Если у вас все LUN идут по порядку, то можно отключить эту функцию, выставив значение 0. В этом случае будет тратиться немного меньше времени на сканирование всех LUN.
Disk.DiskMaxIOSize - с помощью этого параметра можно задать максимальный размер операции ввода-вывода (IO request). По умолчанию, сервер VMware ESX / ESXi поддерживает объем IO-запроса размером до 32767 KB, запросы большего объема разбиваются на части. Для некоторых хранилищ (это надо смотреть в документации) такой размер IO-запроса, генерируемый некоторыми приложениями может оказаться слишком большим и привести к снижению производительности. Поэтому можно уменьшить этот параметр, в зависимости от модели дискового массива. Более подробно описано в KB 1003469.
Disk.SchedQControlVMSwitches - по умолчанию, этот параметр равен 6. Он означает вот что. Когда у нас несколько виртуальных машин отдают свои IO к LUN, у нас вступает в игру параметр Disk.SchedNumReqOutstanding (а не глубина очереди адаптера), который определяет границу для виртуальных машин по одновременной отдаче команд ввода-вывода. Если эта граница превышена - наступает постановка команд в очередь. Но VMkernel должен перед этим обнаружить, что LUN использует несколько ВМ. Так вот Disk.SchedQControlVMSwitches определяет сколько раз должен VMkernel это обнаружить. А понимает он это только тогда, когда следующее IO приходит не от той машины, которая дала предыдущий IO. Надо понимать, что это значение может быть достигнуто не очень скоро, когда у нас есть одна высоконагруженная ВМ A на одном LUN, и там же есть низконагруженная по IO машина (B). И это хорошо, поскольку в таких окружениях не должно быть урезания по вводу-выводу для высоконагруженной ВМ.
Disk.SchedQuantum - по умолчанию, этот параметр равен 8. Он определяет число высокоприоритетных последовательных команд, которые идут к дисковому устройству. Последовательными командами считаются те, которые идут к расположенным рядом секторам диска. Что такое расположенные рядом сектора диска? Это те, которые (по умолчанию) находятся друг от друга на расстоянии не более 2000 секторов. Такие команды выполняются до 10 раз быстрее, чем с далекими секторами.
Disk.SectorMaxDiff - это и есть параметр, определяющий, что такое "близкие" секторы для предыдущего параметра. По умолчанию, он равен 2000.
Disk.SchedQControlSeqReqs - этот параметр (по умолчанию, 128) определяет число последовательных IO без переключений (т.е. последовательность команд только от одной ВМ), после которых счетчик Disk.SchedQControlVMSwitches будет сброшен в 0, а машина сможет использовать опять всю очередь адаптера. Этот параметр нужен для того, чтобы после всплеска нагрузки на ВМ B в первом примере, когда этот всплеск прекратится, ВМ A снова смогла получить в свое распоряжение всю очередь адаптера и дальше работать в интенсивном режиме без входа в игру параметра Disk.SchedNumReqOutstanding, который распределяет IO на LUN.
Воткнули? Нет? Тогда еще раз перечитывайте статью Duncan'а. А еще один блоггер, Andy Grant, нарисовал замечательную картинку (кликабельно):
Мы уже вам надоели с необходимостью подготовки миграции вашей виртуальной инфраструктуры VMware vSphere с хостов ESX на ESXi (поскольку vSphere 5 будет только на базе ESXi), но, все-таки, пролжим деятельность в этом направлении.
Мы уже писали о средстве PXE Manager for vCenter, имеющемся на сайте проекта VMware Labs. Оно нужно для автоматизации развертывания хостов VMware ESXi (Stateless или Stateful) по PXE. Говорят, что утилита войдет в состав VMware vSphere 5. Работает оно только с хостами VMware ESXi, но в версии 4.1 Update 1 утилита получила функцию по миграции хостов ESX на ESXi:
Теперь в утилиту можно добавить хост ESX (предварительно вы уже должны создать образ ESXi):
А далее просто выбрать пункт "Convert this ESX Server to VMware ESXi Server". Дальнейший процесс миграции со скриптом постконфигурации описан в статье Andy Grant "PXE Manager Howto: Converting ESX hosts to ESXi".
Как знают пользователи VMware vSphere, в версии платформы 4.1 появилась новая возможность по управлению приоритетами ввода-вывода виртуальных машин для хранилищ на уровне кластера под названием Storage IO Control (SIOC). Но эта функциональность доступна только в издании vSphere Enterprise Plus, что оставляет множество пользователей за бортом.
В рамках одного хост-сервера VMware ESX / ESXi есть механизм по управлению приоритетами ВМ для хранилищ с помощью Disk Shares (в настройках ВМ). Однако эти приоритеты могут быть заданы только в относительных значениях, что тоже в некоторых случаях неудобно.
В версии VMware vSphere 4.1 появилась возможность задать параметры ограничения ввода-вывода для конкретных ВМ с помощью абсолютных значений (в числе операций в секунду - IOPS и в пропускной способности в секунду - MBps). Это может пригодиться для отдельных виртуальных машин, для которых есть риск "забивания" канала к системе хранения.
Как можно эти параметры добавлять:
Нажмите Edit Settings для выключенной виртуальной машины.
Перейдите на вкладку Options.
В категории Advanced: General нажмите кнопку Configuration Parameters.
Нажмите Add Row.
Далее можно добавить 2 параметра (обратите внимание, что они задаются для каждого виртуального диска):
sched.<diskname>.throughputCap = <value><unit>
Например:
sched.scsi0:0.throughputCap = 10KIOps
sched.<diskname>.bandwidthCap = <value><unit>
Например:
sched.scsi0:0.bandwidthCap = 10KBps
В качестве значений можно использовать буквы K (KBps или KIOps), M (MBps или MIOps) и G (GBps или GIOps). Подробнее в KB 1038241.
По наблюдениям автора, если задать оба параметра для виртуального диска, они будут проигнорированы хост-сервером. А если для каждого диска одной ВМ задать определенные лимиты, то для каждого из этих дисков лимит установится как сумма для двух (то есть, если мы поставим 100IOps и 50IOps, лимит для каждого диска станет 150IOps).
Напоминаю, что работает это только, начиная с VMware vSphere 4.1 (и для ESX, и для ESXi).
Продолжаем вам рассказывать о средстве vGate от компании Код Безопасности, которое необходимо для двух важных с точки зрения информационной безопасности вещей: защиты компонентов VMware vSphere от несанкционированного доступа (НСД) и автоматической настройки среды VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур.
На фоне грядущей ответственности за неисполнения норм ФЗ 152 продукт vGate R2 будет вам очень полезен, тем более, что он имеет сертификат ФСТЭК. Согласно сертификату ФСТЭК России №2308, программное средство защиты информации разработки компании «Код Безопасности» vGate R2 предназначено для защиты от несанкционированного доступа к информации, не содержащей сведения, составляющие государственную тайну, и может применяться в автоматизированных системах уровня защищенности до класса 1Г включительно и в информационных системах персональных данных (ИСПДн) до класса К1 включительно.
А сегодня - еще одна важная новость. В данное время продукт vGate R2 с поддержкой ESXi передан во ФСТЭК России для прохождения инспекционного контроля. Поступление сертифицированного продукта в продажу ожидается в августе 2011 года (т.е. ближе к релизу vSphere 5).
"При разработке новой версии vGate R2 мы постарались учесть все пожелания наших заказчиков. Теперь vGate R2 поддерживает ESXi-сервера, а также содержит новые встроенные наборы шаблонов для АС по требованиям ФСТЭК и для ИСПДН по требованиям СТО БР ИББС. Реализованные в новой версии vGate R2 функции значительно облегчат приведение виртуальных инфраструктур в соответствие законодательству, обеспечат непрерывность в соблюдении политик безопасности и позволят сократить затраты на обеспечение ИБ. На этом мы не останавливаемся и продолжаем дальше развивать vGate с учетом пожеланий наших заказчиков. Сегодня любой желающий может внести свой вклад в развитие vGate, предложив идею относительно развития функционала продукта на нашем сайте", - отметила Мария Сидорова, заместитель руководителя направления "Защита виртуальных инфраструктур" компании «Код Безопасности».
Свой вклад в развитие продукта vGate R2 можно внести, оставив комментарий вот в этой форме на сайте Кода Безопасности.
Скачать пробную версию vGate R2 можно по этой ссылке (вам выдадут лицензию на 60 или 90 дней). В ближайшее время мы подробно рассмотрим механизм защиты информации в виртуальной инфраструктуре VMware vSphere от несанкционированного доступа, а также расскажем о процессе установки vGate R2.
StarWind Enterprise iSCSI Target в виде VSA позволит вам создать хранилища для виртуальных машин VMware vSphere или Microsoft Hyper-V в виде виртуальных серверов хранения (в ВМ), которые развертываются из уже готовой машины StarWind VSA. Для платформ ESX / ESXi и Hyper-V компания StarWind выпустила отдельные версии. Сам виртуальный модуль построен на базе Gentoo Linux и не требует отдельной лицензии Windows.
Отличительная особенность от аналогичных продуктов, поставляемых в виде виртуальных модулей (например, Openfiler) - это то, что с помощью этих модулей можно создать хранилища с высокой доступностью, которые в случае выхода из строя одного из узлов (т.е. ВМ или хост-сервера) мгновенно переключается на работу с синхронизированным резервным хранилищем.
О решении для создания хранилищ StarWind Enterprise iSCSI в виртуальных машинах мы уже писали тут. Его можно использовать для филиалов и небольших компаний, где нет возможности закупить дорогостоящие системы хранения данных, и даже нет денег на покупку отдельных серверов хранения.
Установка продукта StarWind VSA очень проста - вы импортируете виртуальный диск на хранилище VMware ESX или ESXi (понятное дело, что это может быть как локальный том VMFS, так и общее хранилище NFS/VMFS), создаете новую виртуальную машину, к которой подцепляете этот диск vmdk, а также еще один виртуальный диск для хранения данных виртуальных машин, которые будут защищены с помощью высокой доступности.
Конфигурацию машины StarWind VSA рекомендуется сделать такой (пока нет точной информации по этому поводу):
Guest OS - other Linux 64 bit
RAM - 1 GB
2 vNIC
можно поставить paravirtualized SCIS-контроллер для диска с данными
После загрузки этой машины, на стартовом скрине можно будет увидеть IP-адрес, полученный по DHCP, а дальше ее можно подцепить с помощью StarWind Management Console, где уже настраиваются сетевые и прочие параметры:
Процесс установки для платформы Hyper-V в принципе аналогичен. Понятное дело, когда выйдет релизная версия StarWind VSA, она будет поставляться в виде виртуального модуля OVF, чтобы машину можно было сразу импортировать на ESX.
Насчет логина и пароля к Linux-консоли StarWind VSA. Это vsa и starwind, соответственно. Для добавления VSA к консоли управления логин и пароль остались теми же: root и starwind.
Скачать StarWind VSA сейчас можно бесплатно и без регистрации с пробной лицензией на 120 дней по этой ссылке.
Как знают администраторы систем хранения данных, у различных компонентов SAN-сети есть такой параметр как глубина очереди (Queue Depth). Он есть у HBA-адаптера сервера (на котором, например, работает VMware ESX / ESXi) и у порта Storage Processor'а системы хранения (SP). Глубина очереди определяет сколько операций ввода-вывода (IO) может быть одновременно обработано на устройстве.
Как мы уже писали, если до SP со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (T) должна удовлетворять следующему соотношению:
T >= Q*L,
где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.
Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:
T>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.
Queue Depth на серверах
По умолчанию, для хостов VMware ESX / ESXi значение Queue Depth равно 32, как его изменить, читайте у нас тут и вот тут. Теперь внимание: этот параметр имеет значение только когда у вас только одна виртуальная машина на хост-сервере использует конкретный LUN. Если его используют уже 2 машины, то он игнорируется, а в действие вступает следующая расширенная настройка (Advanced Setting - как его задавать описано тут):
Disk.SchedNumReqOutstanding (DSNRO)
Этот параметр также по умолчанию равен 32. Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN. То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в статье Jason Boche, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32:
Здесь видно, что активно выполняется 30 команд (максимально 32) для параметра DQLEN, а остальные 67 остаются в очереди. То есть параметр определяет максимальную планку в IO как для одной машины на LUN, так и для всех машин на LUN.
Важно, чтобы параметры Queue Depth и DSNRO были установлены в одно и то же значение. Это рекомендация VMware. Так что, если вздумаете изменить один из них - не забудьте и про второй. И помните, что параметр DSNRO для хоста - глобальный, а значит будет применяться ко всем LUN, подключенным к хосту.
Target Port Queue Depth на массивах
Для дискового массива (а точнее, SP) очередь - это то, куда он сладывает SCSI-команды в то время, пока обрабатывается и выполняется пачка предыдущих. Нормальный midrange-массив имеет глубину очереди 2048 и более. Если массив получает в очередь команд IO больше значения Target Port Queue Depth, то он назад выдает команду QFULL, которая означает, что очередь заполнена и хост-серверу нужно с этим что-то делать. VMware ESX / ESXi реагирует на это следующим образом - он уменьшает очередь на LUN и периодически (каждые 2 секунды) проверяет, не исчезло ли QFULL, и если исчезло, то начинает постепенно увеличивать глубину очереди для этого LUN (это может занять до одной минуты). Это и есть причины тормозов, которые часто возникают у пользователей VMware ESX / ESXi.
Как управлять очередью и адаптивный алгоритм VMware
Теперь становится понятным, почему мы сразу не выставляем параметр Disk.SchedNumReqOutstanding на хостах VMware ESX / ESXi в максимальное значение - мы можем вызвать QFULL на SP массива. С другой стороны, уменьшать его тоже нехорошо - мы ограничим количество операций IO с хоста на LUN.
Поэтому здесь нужен гибкий подход и он есть у VMware (adaptive queue depth algorithm). Работает он таким образом: мы его активируем с помощью параметров Disk.QFullSampleSize и Disk.QFullThreshold в Advanced Settings. Они влияют вот на что:
QFullSampleSize - если число число ответов QFULL (оно же BUSY) превысит его, то ESX / ESXi наполовину обрежет глубину очереди (LUN queue depth)
QFullThreshold - если число ответов о том, что QFULL или BUSY больше нет, превысит его, то ESX / ESXi будет постепенно увеличивать LUN queue depth на 1 (вроде бы, каждые 2 секунды).
Но сколько бы не уменьшалось DQLEN - ниже заданного нами значения DSNRO оно не упадет. Это защищает нас от неожиданного провала в производительности. Кстати, эти параметры тоже глобальные - так что если один (например, тормозящий) массив с хоста будет подвергаться такому адаптивному эффекту со стороны ESX / ESXi, то и для другого (например, производительного) тоже будут выполняться такие фокусы.
Теперь, что дополнительно можно почитать на эту тему:
То есть мораль всей басни такова - дефолтные зачения DSNRO и Queue Depth подходят для большинства случаев. Но иногда имеет смысл изменить их. Но в этом случае надо учитывать параметры системы хранения данных, структуру SAN, количество LUN и другие параметры, влияющие на производительность ввода-вывода.
Как вы знаете, есть такой хороший продукт vGate 2, который производится нашим спонсором - компанией "Код Безопасности" (об основных его возможностях можно почитать в нашей статье). Нужен он для двух важных с точки зрения информационной безопасности вещей: защиты компонентов VMware vSphere от несанкционированного доступа (НСД) и автоматической настройки среды VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги, которые вы должны были бы потратить на консультантов, обучение своих специалистов и ручную настройку виртуальной среды).
Кстати, важная новость. Вышел vGate 2 с полной поддержкой VMware ESXi 4.1 (об этом мы писали тут, но продукт был еще в бете). Скачать vGate 2 для VMware ESXi можно тут.
Но сегодня мы поговорим о том, как было бы неплохо организовать безопасную инфраструктуру доступа системных администраторов VMware vSphere к различным компонентам среды виртуализации. Это нужно для того, чтобы понимать как правильно наладить контроль за серверами ESX / ESXi и виртуальными машинами со стороны vGate, а также разграничить доступ к этим объектам в рамках зон ответственности администраторов vSphere.
Логичной выглядит следующая схема построения локальной сети в контексте доступа к компонентам виртуальной инфраструктуры:
Немного опишем ее:
Выделяем на уровне домена безопасности отдельно сеть администрирования инфраструктуры vSphere. Она содержит серверы ESX / ESXi, сервер vCenter, а также сервер авторизации vGate. Сам сервер авторизации имеет два сетевых адаптера - одним он смотрит в сети администрирования vSphere, а другим во внешнюю сеть предприятия, где находятся рабочие станции администраторов. Таким образом из последней сети в сеть управления можно попасть исключительно через сервер авторизации vGate (компоненты vGate выделены зеленым). На рабочих местах администраторов vSphere и администратора ИБ также установлены клиентские компоненты vGate.
В отдельную подсеть нужно выделить сеть репликации ВМ (та, что для vMotion и Fault Tolerance).
В отдельную подсеть выделяем сеть для IP-хранилищ (NFS/iSCSI).
Ну и, само собой, сеть виртуальных машин тоже должна быть отдельной. Разделение сетей на хостах ESX / ESXi лучше делать на базе тегирования на уровне виртуального коммутатора (см. виды тэгирования).
Если взглянуть на разделение сетей со стороны сетевых адаптеров хост-сервера ESX сервера авторизации vGate, мы получим такую картину:
После конфигурирования локальной сети обязательно следует настроить маршрутизацию между подсетями, а также убедиться в наличии доступа с рабочих мест администраторов vSphere к элементам управления виртуальной инфраструктурой (vCenter и хост-серверы).
Вот основные варианты настройки маршрутизации (АВИ - это администратор виртуальной инфраструктуры):
При внесении различных параметров в конфигурационные файлы виртуальной машины на VMware ESX могут возникнуть различные ошибки. При этом виртуальная машина может до некоторого времени работать корректно.
Есть способ проверить vmx-файл на предмет наличия в нем ошибок (опечаток, например, в путях к рабочим директориям и т.п.). Для этого есть команда:
/usr/bin/vmware-configcheck <путь к vmx-файлу>
Она проверяет его на соответствие правилам оформления, приведенным в файле /etc/vmware/configrules.
В случае успешной проверки результат будет таким:
А в случае неуспешной - будет выведен результат FAIL и описание ошибки конфигурации.
В первой части статьи о файлах журнала VMware ESX (логах) мы описали их размещение и назначение. Но поскольку готовящаяся к выходу платформа VMware vSphere 5 будет построена только на базе платформы VMware ESXi (см. нашу серию статей), то сегодня мы поговорим о том, где находятся логи ESXi и как их можно посмотреть.
Если открыть консоль ESXi через консоль Tech Support Mode или по SSH мы можем увидеть следующую структуру основных логов:
/var/log/vmware/hostd.log – это лог службы хоста VMware ESXi (host daemon - служба, управляющая хостом)
/var/log/vmware/vpx/vpxa.log – лог агента vCenter (который управляет через агент хоста). Этого лога не будет если ESXi работает не под управлением vCenter.
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
/var/log/sysboot.log - System boot log (лог загрузчика хоста)
/var/log/vmware/aam/vmware_<hostname>-xxx.log - Automatic Availability Manager (AAM) logs (лог агента VMware HA). Этого лога не будет если ESXi работает не под управлением vCenter.
NB: Обратите внимание, что при установке VMware ESXi по умолчанию логи хранятся в разделе Scratch Partition, который находится в памяти в виде RAM-диска. После перезагрузки хоста - они будут удалены, если вы не настроили этот раздел для хранения, в том числе, логов.
Теперь как эти логи на ESXi можно посмотреть. Есть аж 5 способов.
1. Через DCUI (Direct Console User Interface).
В главном меню System Customization, куда вы попадаете по кнопке F2 на самом сервере, выберите пункт "View System Logs":
Также в DCUI можно по комбинации клавиш Alt+F12 увидеть лог vmkernel.
Также вы можете зайти в консоль и перейти в папку с логами (/var/logs):
2. Через веб-браузер.
Просто наберите в адресной строке https://<esxi ip address>/host, после чего введите имя пользователя и пароль root.
3. Использование Syslog-сервера для VMware ESXi.
Вы можете настроить Syslog-сервер для ваших хостов ESXi в целях организации удаленного логирования. Для этих целей вполне можно использовать бесплатный продукт vSphere Management Assistant (vMA). Подробно это описано тут:
Кстати, по умолчанию сообщения логов vpxa и hostd (/var/log/vmware/vpx/vpxa.log и /var/log/vmware/hostd.log) дублируются в /var/log/messages. Если вы хотите это отключить (чтобы там было меньше флуда), используйте вот эту заметку.
Продолжаем вас знакомить с решением vGate 2 от компании Security Code, которая является нашим спонсором (вот тут описано решение, а вот тут - специальный раздел о продукте). Вкратце: vGate 2 позволяет защиту объектов VMware vSphere от несанкционированного доступа, а самое главное - позволяет автоматически настроить среду VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги). Кстати, недавно вышла версия vGate 2.3 с поддержкой VMware ESXi.
Сегодня мы поговорим о мониторинге и аудите событий информационной безопасности, происходящих в виртуальной инфраструктуре VMware vSphere. Надо сказать, что для тех компаний, которые заботятся о безопасности своих виртуальных серверов, анализировать стандартные логи, которые дает ESX и vCenter весьма муторно:
На хостах ESX структура логов (откуда мы и можем выделить события ИБ) такова:
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
Вручную разгребать и анализировать всю эту пачку весьма трудозатратно, поэтому vGate 2 дает вам возможность сделать это удобно из центральной консоли в едином Журнале событий. Но vGate 2 - это не обработчик логов на хостах VMware ESX / ESXi. За счет собственных агентов на хост-серверах он сам регистрирует все события, относящие к информационной безопасности инфраструктуры виртуализации. Это именно те события, аудит которых позволяет своевременно обнаружить и пресечь попытки несанкционированного доступа.
События безопасности регистрируются на всех серверах ESX, на которых установлены компоненты защиты vGate (агенты), а затем пересылаются на сервер авторизации для централизованного хранения. Регистрируются как события несанкционированного доступа к объектам vSphere, так и правомочные события.
Если открыть одно события из списка, мы увидим нечто подобное (доступно полное детальное описание - кто сделал, что, когда и с какого хоста):
События имеют следующие характеристики:
vGate 2 отслеживает те события, которые могут тем или иным образом повлиять на безопасность виртуальной инфраструктуры. Как примеры таких событий можно привести следующее:
Также, помимо основных событий, vGate 2 регистрирует еще и события, связанные с нарушением контроля целостности (КЦ) в различных компонентах виртуальной инфраструктуры:
На серверах ESX (папка /opt/vgate)
На сервере авторизации (каталог установки vGate)
На рабочей станции администратора VMware vSphere
На рабочей станции администратора безопасности инфраструктуры vSphere
Кстати, на компьютерах внешнего периметра сети администрирования (то есть рабочих станциях с vSphere Client), на которых установлен агент аутентификации, сообщения хранятся локально в журнале при
ложений Windows (Application Event Log). Для их просмотра (локально или удаленно) можно использовать Windows Event Viewer.
В этом документе вы найдете полное описание событий ИБ на хостах VMware ESX / ESXi, которые регистрирует vGate 2.
В заключение скажем, что vGate 2 имеет возможность интеграции с SIEM-системами, если таковые имеются на вашем предприятии. vGate позволяет настроить ведение журнала событий и поддерживает протокол SNMP, что позволит при необходимости перенаправить события из журнала событий vGate на удаленный сервер.
Как оказалось, на нашем сайте нет хорошего руководства по назначению и использованию RDM-дисков (Raw Device Mapping) с платформой VMware vSphere. Постараемся заполнить этот пробел.
Давайте начнем с того, что для виртуальных машин на серверах VMware ESX есть всего 3 типа дисков с точки зрения виртуализации подсистемы хранения:
VMDK-диски
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion - и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски - это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором - это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS - не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом - основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе - дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности - например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
Как вы знаете, мы сотрудничаем с компанией "Код Безопасности", которая, в частности, занимается выпуском продукта vGate 2, который автоматизирует настройку виртуальной среды в соответствии с регламентами предприятия, а также руководящими документами и стандартами в этой сфере (см. тут). Кроме того, он позволяет организовать инфраструктуру полномочного доступа к компонента виртуальной инфраструктуры VMware vSphere и защитить ее от несанкционированного доступа (см. тут).
Недавно стала доступна для скачивания бета-версия продукта vGate 2.3, который полностью поддерживает платформу VMware ESXi 4.1. А это очень важно, поскольку vSphere 5 будет построена только на базе ESXi, а ESX уйдет в прошлое (см. нашу серию статей тут). Само собой, к выходу vSphere 5 продукт vGate будет готов обеспечивать безопасность этой платформы.
Итак, прежде всего, ссылка на скачивание vGate 2.3 с поддержкой ESXi: http://www.securitycode.ru/products/demo/. В поле "Выберите продукт" выбираем "Бета-версия vGate 2 (с поддержкой ESXi)".
Для поддержки ESXi была проделана большая работа - представьте сколько всего нужно было переделать, чтобы доработать агента для хост-серверов и договориться с VMware о его сертификации для ESXi. Под "все" подразумевается настройка конфигурации хост-серверов ESXi для соответствия политикам безопасности VMware Security Hardening и другим.
Важно! Для серверов виртуализации VMware ESXi пока поддерживаются только следующие политики:
Запрет клонирования виртуальных машин;
Запрет создания снимков виртуальных машин;
Список запрещенных устройств;
Доверенная загрузка виртуальных машин;
Запрет подключения USB-носителей к ESX-серверу;
Очистка памяти виртуальных машин;
Запрет доступа к консоли виртуальной машины;
Запрет доступа к файлам виртуальных машин;
Затирание остаточных данных на СХД при удалении ВМ;
Запрет смешивания разных типов сетевого трафика.
Кстати, если у вас есть инфраструктура VMware View 4.5 - то vGate 2.3 ее поддерживает (в документации описано, что нужно сделать).
В продукте появилось еще несколько интересных возможностей:
Поддержка стандартного Distributed vSwitch (dvSwitch)
Новые политики безопасности:
Запрет Download файлов ВМ с привязкой к меткам
Запрет трафика vMotion (FT) и трафика vSphere Client
Затирание остаточных данных на СХД при удалении ВМ
Запрет доступа к консоли ВМ с привязкой к меткам
Соответствие стандарту PCI-DSS
Обновлен установщик продукта, улучшено управление генерацией событий
Сервер авторизации полностью поддерживается в ВМ
Шаблоны настроек политик АС по ФСТЭК, ИСПДн по ФСТЭК, ИСПДн по СТО БР ИББС
В продолжение темы "Как сбросить пароль root на VMware ESX". У Dave Mishchenko есть отличная инструкция о том, как сбросить пароль пользователя root на хосте VMware ESXi в том случае, если вы его потеряли, забыли или съели. Работает эта инструкция и для VMware ESXi 4.1 (а также 4.0 и даже 3.5). Переведем ее вкратце.
1. Допустим хост VMware ESXi у вас сейчас работает и вы можете выполнять на нем команды локально или по SSH. Тогда имеет смысл выполнить команду:
cat /etc/shadow
Видим картинку с хэшем пароля рута:
Хэш пароля - это то, что написано после root : до следующего двоеточия (само двоеточие не включается). Хэш этот нужно записать на случай, если его понадобится восстановить назад.
2. Дальше нужен какой-нибудь Linux live CD. Предлагается использовать Slax Linux Live CD.
Далее просматриваем смонтированные разделы сервера ESXi командами:
fdisk -l (смотрим подходящие FAT16 разделы, где у нас размещен загрузчик)
ls -l /mnt/sda5/ (основной, при загрузке монтируется как /bootbank)
ls -l /mnt/sda6/ (резервный, при загрузке монтируется как /altbootbank)
В случае чистой установки ESXi, картина будет такова:
Нас интересует файл state.tgz - там все, что нам нужно. Если у вас ESXi Embedded то нужен файл local.tgz (который в первом случае находится внутри state.tgz).
Распаковываем сначала state.tgz, а потом local.tgz командами gzip и tar во временную директорию. Далее заходим в ней в папку /etc и открываем в ней файл shadow командой:
vi shadow
У вас откроется что-то вроде того:
Теперь посмотрите на картинку ниже, мы удаляем хэш пароля из этого файла:
То есть убираем все то, что между двумя двоеточиями. Выходим из файла, сохранившись.
Теперь все это упаковываем назад, для чего во временной папке (туда надо подняться из /etc) выполняем такую команду (апдейтим архив изменившейся папкой):
tar -czvf local.tgz etc
Если вы используете ESXi Embedded - кладете файл local.tgz на место, откуда брали. Если обычный ESXi - снова апдейтим архив:
tar -czvf state.tgz local.tgz
И также копируем туда, где он лежит:
Перезагружаем сервер и уже загружаемся в VMware ESXi. Видим такую картинку:
Это значит - все получилось. Теперь можем заходить в консоль под пользователем root с пустым паролем. Вот такой незамысловатый способ сброса пароля на хосте VMware ESXi.
Вы уже все знаете про продукт StarWind Enterprise iSCSI (но еще не все купили), который позволяет создавать отказоустойчивые хранилища для виртуальных машин VMware vSphere и Microsoft Hyper-V (у нас есть, кстати, специальный раздел о StarWind). Недавно мы писали о том, что вышла бесплатная версия StarWind Free.
А сегодня еще одна приятная новость для задумавшихся о покупке продукта - теперь StarWind Enterprise полностью сертифицирован со стороны VMware в качестве системы хранения по программе VMware Certified Partner. Вы можете обнаружить его в HCL-листе:
Из пресс-релиза:
StarWind iSCSI SAN software has successfully passed all the laboratory tests and has met all the interoperability criteria required by VMware.
This certification assures our customers that StarWind solution is officially compatible with VMware virtualization products and guarantees full VMware technical support for any VMware infrastructure built using StarWind iSCSI SAN.
Так что теперь можете смело показывать руководству, что iSCSI-хранилища StarWind Enterprise - это сертифицированное VMware решение.
Начните хотя бы с бесплатной версии - это не потребует от вас ничего кроме обычного Windows-сервера, который даже может быть виртуальным. Кстати, скоро выйдет версия StarWind Enterprise 5.7, где будет еще больше возможностей.
Те, кто увлекается разработкой сценариев на PowerShell на фреймоврке PowerCLI, наверное помнят про бесплатную раздачу постеров на блоге VMware. Тогда не все успели забрать свой постер.
Сейчас они пишут, что раздача закончена. Но не беда - вы без проблем можете забрать свой постер по PowerCLI по этой ссылке. А вот еще версия для распечатки на листах А4.
Вы все уже давно поняли, что нужно думать о безопасности виртуальной инфраструктуры VMware vSphere. Лучше всего думать о ней таким способом: попробовать продукт vGate, который автоматизирует настройку виртуальной среды в соответствии с регламентами предприятия, а также руководящими документами и стандартами в этой сфере. Сегодня мы рассмотрим безопасность инфраструктуры виртуализации с экономической точки зрения: попробуем ROI-калькулятор для решения vGate.
RSS
